C# Enum To Text Extension Goodness


using Savaged.Info.EnumToString;
using Savaged.Info.Models;

namespace Savaged.Info.Console
{
  class Program
  {
    static void Main(string[] args)
    {
      var payment = new Payment() { StatusID = 3 };
      System.Console.WriteLine("Status ID:{0} as Enum {1} and as String '{2}'.",
        payment.StatusID, (PayRecs)payment.StatusID, payment.Comment);
      System.Console.ReadKey();
    }
  }
}

namespace Savaged.Info.EnumToString
{
  public enum PayRecs
  {
    _,
    PayInFull,
    PartPay,
    WithholdInFull,
    Logged,
    Accept,
    WrittenOff,
    ReferToFinance,
    DoNotAccept,
    CopyForInfo,
    PayRec,
    Closed
  }

  public static class PayRecsExtensions
  {
    public static string Text(this PayRecs payRec)
    {
      var value = string.Empty;
      switch (payRec)
      {
        case PayRecs.PayInFull:
          value = "Pay in full.";
          break;
        case PayRecs.PartPay:
          value = "Part pay.";
          break;
        case PayRecs.WithholdInFull:
          value = "Withhold in full.";
          break;
        case PayRecs.Logged:
          value = "Logged for action.";
          break;
        case PayRecs.Accept:
          value = "Accept in full.";
          break;
        case PayRecs.WrittenOff:
          value = "Amount written off.";
          break;
        case PayRecs.ReferToFinance:
          value = "Refer to Finance.";
          break;
        case PayRecs.DoNotAccept:
          value = "Do not accept.";
          break;
        case PayRecs.CopyForInfo:
          value = "Copy for info.";
          break;
        case PayRecs.PayRec:
          value = "Payment recommendation.";
          break;
        case PayRecs.Closed:
          value = "Closed.";
          break;
      }
      return value;
    }
  }
}

namespace Savaged.Info.Models
{
  public class Payment
  {
    private int _statusId;
    private decimal _demanded;
    private decimal _demandedVAT;
    private decimal _recommended;
    private decimal _recommendedVAT;

    public Payment()
    {
      // Logic for setting fields like demanded
      _demanded = 1234.56M;
      _demandedVAT = _demanded * 0.2M;
    }

    public int StatusID
    {
      get => _statusId;
      set
      {
        _statusId = value;
        switch (value)
        {
          case (int)PayRecs.PayInFull:
          case (int)PayRecs.Accept:
            _recommended = _demanded;
            _recommendedVAT = _demandedVAT;
            break;
          case (int)PayRecs.DoNotAccept:
          case (int)PayRecs.Logged:
          case (int)PayRecs.WithholdInFull:
            _recommended = 0;
            _recommendedVAT = 0;
            break;
        }
        if (string.IsNullOrEmpty(Comment))
        {
          Comment = ((PayRecs)value).Text();
        }
      }
    }

    public string Comment { get; set; }
  }
}


link hint

//////////////////////////////////////////////////////////////////////
//                                       _       _        __        //
//                                      | |     (_)      / _|       //
//   ___  __ ___   __ _ _  __ _  ___  __| |      _ _ __ | |_ ___    //
//  / __|/ _` \ \ / / _` |/ _` |/ _ \/ _` |     | | '_ \|  _/ _ \   //
//  \__ \ (_| |\ V / (_| | (_| |  __/ (_| |  _  | | | | | || (_) |  //
//  |___/\__,_| \_/ \__,_|\__, |\___|\__,_| (_) |_|_| |_|_| \___/   //
//                         __/ |                                    //
//                        |___/                                     //
//                                                                  //
//////////////////////////////////////////////////////////////////////

C# Tuple Goodness

Since learning of the improved implementation of Tuples in C# 7.0 I have been looking for the right time to leverage them. When I wanted a factory to split an server API result into a set of sub-types I thought this was my chance.

Below my server (a PHP/Laravel Rest Service) provides a call for all the Notes on the system. It includes a property ‘Type’ to specify which part of the system the Note is against. I wanted to make that more OO in my desktop application. I thought a loose interpretation of the factory pattern would be best. As I wanted one call that returns a set of collections each of a different sub-class of Note, I thought a Tuple would work well.

using System;
using System.Linq;
using System.Collections.Generic;
using System.Threading.Tasks;
using Desktop.Auth;
using Desktop.Facades;
using Desktop.Interfaces;
using Desktop.Models;

namespace Desktop.ViewModels.Utils
{
    class NotesFactory where NotesParentType : IModel
    {
        private IMainFacade _facade;

        public NotesFactory(IGateway gateway)
        {
            var g = gateway ?? throw new ArgumentNullException(nameof(gateway) + " cannot be null.");
            _facade = new MainFacade(g, CurrentUser.Instance.Token);
        }

        public async Task<(IList schemeComments,
            IList schemeAlerts, 
            IList storeComments,
            IList storeAlerts)>
            AllNotesOf(
            NotesParentType notesParent, 
            bool withHidden, 
            ServiceTypes serviceType, 
            Action reactionToException)
        {
            var args = new Dictionary<string, object>
            {
                { "WithHidden", withHidden },
                { "ServiceType", serviceType.ToString() }
            };
            var allNotes = await _facade.IndexByRelation(notesParent, reactionToException, args);

            var baseSchemeComments = allNotes.Where(n => n.Type == "SchemeComment");
            var baseSchemeAlerts = allNotes.Where(n => n.Type == "SchemeAlert");
            var baseStoreComments = allNotes.Where(n => n.Type == "StoreComment");
            var baseStoreAlerts = allNotes.Where(n => n.Type == "StoreAlert");

            var schemeComments = CopyTo(baseSchemeComments);
            var schemeAlerts = CopyTo(baseSchemeAlerts);
            var storeComments = CopyTo(baseStoreComments);
            var storeAlerts = CopyTo(baseStoreAlerts);

            return (schemeComments, schemeAlerts, storeComments, storeAlerts);
        }

        private static IList CopyTo(IEnumerable notes) where T : Note, new()
        {
            IList list = new List();
            foreach (var note in notes)
            {
                var t = new T();
                note.CopyTo(ref t);
                list.Add(t);
            }
            return list;
        }
    }
}

2011 in review

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 2,600 times in 2011. If it were a cable car, it would take about 43 trips to carry that many people.

Click here to see the complete report.

IT and customer as trusted friends

It’s not uncommon for an organisation’s ‘mission, vision & values’ to include a set of core elements, and then to see an aspect covering customer relations. This brief post focuses on the “customers” element and how an IT change department benefits from a modern view of this relationship.

Expressions such as “the customer is always right” or “the customer is king” are familiar, however in our modern complex environment, these concepts are outdated and outmoded. This is reflected in a more modern vision where we find the customer relationship described as one more like that between trusted friends.

Trusted friends are on equal terms and is a relationship based on respect; seeing each other ‘eye to eye’. If such a friend were taking some false step, a friend with the authority of expertise, would look to readjust their thinking; even having to “just say ‘no’ when necessary”. As a practical application of this principle, an example might be a demand to skip adequate testing during delivery; whereas we would need to help our customer to see the danger of building technical debt.

Rather than being exclusively ‘delivery focussed’ we offer our customer a mature long term point of view; in effect we offer a service of ‘strategic technical conscience’.

A quote from George MacDonald sums this up well: “To be trusted is a greater compliment than being loved.”

A crucial aspect of the ‘trusted friend’ customer relationship is understanding them. We must do all we can to know our customer. Once we have a reasonable understanding of the complexity they face and the priorities they have, we must help them to understand our similar challenges. These of course include a strategy of producing robust and extensible software.

A powerful way to facilitate the mutual understanding is to employ a methodology rather than continuing an informal ad-hoc development approach. Agile for discrete projects or Lean techniques for more business-as-usual change, afford opportunity for bi-lateral engagement; understanding and sharing priorities, concerns and constraints.

In short, IT can and should be a trusted friend to our customer, and this in many cases requires us to re-evaluate our behaviour.

Agile adoption – missing a trick?

It’s been my experience that planning, prioritisation and activity transparency get the lion’s share of attention when teams are taking the Agile adoption journey. There may even be many who say that list covers all there is to Agile.

Of course focus on these aspects is essential, but should other valuable features be eclipsed? For example, is the adoption of pair-programming or peer-reviewing followed with the same diligence as the daily stand-up? Is the practice of ‘test first’ techniques as mature as the implementing of a Story-Wall or Kanban for instance?
Time for a metaphor!

The American muscle car versus the European sports car. The former is all about power, whereas the latter is often a balance of power and cornering. Let’s say a greenfield project is the long straight road that the muscle car is made for. Now let’s liken the winding track over the Alps to the route of the product already in production that is constantly being enhanced and refactored.  Fast pace forward is useful but you’ll need to be able to adjust course without losing control.

Perhaps it’s no big surprise that the more project management side of Agile gets more focus. It’s often managers that get to set the agenda for Agile adoption and frequently they’ll focus on the classical project management aspects of software change delivery. Additionally or possibly symptomatically, Scrum is most often the framework latched onto as the Agile adoption solution. We’ll be great at moving forward at quicker a more predictable pace when we implement this aspect of Agile. We’ll be behind the wheel of a powerful machine ready to drag race with the project teams who are yet to adopt it. Yes Scrum is powerful; but it was intentionally designed as complementary to Agile practices found in other frameworks like Extreme Programming.

In many organisations the project management aspects of Agile are a massive challenge for adoption. We should continue to push for the transformation required to make that happen. But in the meantime are we missing a trick? Are we missing out on the value of adopting the rest of Agile, most of which does not require such organisation-wide transformations. Things like TDD or BDD and pair-programming are mostly in the control of the development team. There may be some resistance at first but this can be countered with some good selling: clear measurable comparisons of effort spent before and after.

The ‘test first’ approach and continuous-integration build in the ability to adapt to frequent changes in requirements. It creates courage to refactor and nibble away at technical debt. And pair-programming can get us headed in the right direction for achieving technical excellence and mitigating key-man risk. Thinking back to our metaphor, we swap our straight line project muscle car power for the European sports car that’s performant and adaptive; one that makes us confident to take those mountain hairpin corners.

Changing from how things have always been is never easy, even when the desire is present. At the very least however, why not make sure the agenda is properly balanced in your Agile discussions and adoption planning?

going Agile? turn right at the waterfall

When offering directions for someone to get somewhere often the factor having the most impact on success or failure is finding a common point of reference. For example, if someone who has only ever known South London were to ask how to get to Big Ben, of how much benefit would references to North London locations be?

Perhaps we make a similar mistake with offering directions on the journey to Agile adoption. Almost without exception a challenge about whether there’s any worth in changing to Agile is met with references to Waterfall. But if Waterfall were North London, most have rarely even taken a day trip! By far the majority come from a ‘South London’ of ad-hoc software development.

For such fast paced, tough skinned development teams a Waterfall reference has no bearing on the journey they take. The most significant impact of this bad habit we must unlearn is that it’s virtually impossible for those needing directions to see any value in even setting off.

Here are a few suggested more familiar ‘landmarks’ and possible directions:

Familiar ‘Landmark’	Possible Direction	Benefit
The single page hand-written spec	Granular user stories with acceptance criteria	Small units of work with an agreed outcome
The occasional unscheduled catch-up	Daily ‘stand up’ around a ‘story wall’	Clear and scheduled communication
The “we need it now” delivery plan	Fixed length iterations with agreed content	Constantly improving planning & estimation
The “there’s no time for more testing”	Test driven development & continuous integration	Time reclaimed by stable & reliable releases
The regular heated moment	Structured & disciplined methodology	Managed expectations & improved communications

So the next time someone asks “what’s the point of Agile” or “aren’t we already Agile enough”, remember to offer familiar points of reference and the accompanying feature and benefit. Thus improving the chances of them seeing the value of the Agile journey.

 

agile projects bundled with maintenance?

A quick posting to highlight three blog articles; each an aspect on using Agile for maintenance, or alternatives, as the case may be:

• Agile for Maintenance
• Should you have separate product and maintenance teams?
• Agile Infrastructure Projects – Lessons Learned

2010 in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

The Blog-Health-o-Meter™ reads This blog is doing awesome!.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 1,900 times in 2010. That’s about 5 full 747s.

 

In 2010, there were 4 new posts, growing the total archive of this blog to 103 posts. There were 9 pictures uploaded, taking up a total of 869kb. That’s about a picture per month.

The busiest day of the year was September 22nd with 28 views. The most popular post that day was mix agile development with waterfall project management and get fragile.

Where did they come from?

The top referring sites in 2010 were blog.mountaingoatsoftware.com, google.com, en.wordpress.com, maiaandalan.fireflyinternet.co.uk, and linkedin.com.

Some visitors came searching, mostly for agile development life cycle, vim grails, agile development, agile vs waterfall, and grails vim.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

mix agile development with waterfall project management and get fragile January 2010
6 comments

2

gantt project report gan2html.xsl October 2006
9 comments

3

my pain with a .Net web-service and a Java (AXIS) client July 2006
4 comments

4

UK TV License required for broadband BBC broadcasts? June 2006
14 comments

5

groovy minimalism July 2009

my brief Agile faith crisis

Recently I was labelled “religious” about Agile. For a few days thereafter I agonised about whether I have taken a purist, ideological and dogmatic stance that could block innovation. Or perhaps worse still, slow people down who are getting things done. I find myself at odds with the majority. In short, a crisis of faith!

My crisis leads to questioning what could be so wrong about tailoring Agile to fit whatever the situation calls for? What could be the harm in taking the bits of Agile that suit and discarding the less well-fitted?

I turn to the gurus and sages, the Agile thought leaders. What do they have to say about which principals are essential? the fundamentals without which Agile is just not Agile? There are a few classic quotes, for instance Alistar Cockburn and Ken Schwaber’s comments about Scrum with beginners and Ken’s request not to use the Scrum brand once it has been tinkered with – Scrum as a Framework. Interestingly, deviations far from the fundamentals are labelled “Smells”. Here are a few examples: Loss of Rhythm; Missing Pigs. It’s worth making the time to watch this presentation about Scrum at Google, in which these fundamentals stand out.

There may be some gains in taking parts of Agile and these might get things done. Equally there could be side-effects that build up and make people less efficient (I’ve witnessed this in action). Besides the possibility of unwanted byproducts, there’s the missed opportunity! Agile when implemented with all it’s fundamentals in-place is designed to show up weaknesses early. Done properly it highlights what a whole organisation needs to change to make itself better. It is “the canary in a coal mine“. If we only take the bits that “get things done” we only maintain the status quo, or more likely we build a legacy that slowly chokes our organisation.

In the end, as a self-styled Agile evangelist, it comes down to communication. More precisely, presentation of the message in such a way that it is palatable, without loosing it’s nutritional value – Agile seasoned with salt. Timing too, not when the appetite is present, because those on milk may feel satisfied, but timing in the sense of a gradual transition to solid food.

A common failing of those with a sense of strong faith is to couple it with a sense of elevation and even superiority over the unbelievers. Of course this polarises and alienates. A further failing then often follows, namely extremism. This characterises absolute failure! Destructive rather than the desired constructive outcome. Alienating rather than contributing. To be avoided at all costs. No, more than that: it demands reevaluation; readjustment.

In short, I have learnt from the experience. I’ve learnt that I need to make changes myself, and at the same time maintain my firmly held belief. My confident belief that the rewards of the narrow road outweigh the comforts of the broad. Wow, it’s remarkable how many religious metaphors this blog led to – ok, I’m religious about Agile, but I’m keenly aware of the need not to alienate and to collaborate allowing time for growth when we can reap the benefits together.